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INTERVIEW AGENDA 

Interview Date: August 28, 2008, 10:30 a.m. 



Application No. 1 0/620,769 

First Named Applicant: FOSTER^ ET AL. 

Group Art Unit: 2182 

Examiner: Tanh Q. NGUYEN 

Status of Application: Pending - Non-Final Office Action issued April 30, 2008 



In paragraph 2 of the Office Action, the Examiner objects that claim 34 is different from 
what is disclosed in the application as filed. 

As the Examiner has appreciated, claim 34 i$ based on the fourth embodiment. Page 24 
from line 1 5 states that: 

"According to a fourth embodiment, a synchronous trigger signal for a transducer 
on a given device is produced by using the SOF packet including the encoded 
frame number, to trigger a transducer at a given time." 

This clearly teaches a method whereby a trigger signal (viz. physical action) is generated 
when the device receives an SOF packet with a specific frame number. The person of 
ordinary skill in this art will immediately understand that reference to a trigger signal 
implies the use of a "trigger request signal" to "initiate" or pre-configure the device to 
perform its action (i.e. be triggered) upon receipt of a specifically numbered SOF packet. 
Though not referred to explicitly in the context of the fourth aspect of the invention as 
filed (being regarded as implicit), reference is made to a "trigger request signal" earlier in 
the summary of the invention (see page 13 lines 28 and 29) in a manner that distinguishes 
it from a trigger command signal. 

Also, the trigger request signal is merely a message that configures the device to act upon 
receipt of the trigger command signal. The trigger command signal (explicitly recited in 
this aspect of the invention as filed) is emphasized because it is that signal that is actually 
decoded from the data stream. An SOF packet is not adapted to contain information 
about what action to take and hence the trigger command signal, as it is a packet defined 
by the USB specification and so essentially reserved. It would thus be readily understood 
by those of ordinary skill that, if the SOF packet generates the trigger command signal, 
an earlier message (in fact the trigger request signal) must have been sent to define what 
action to take on receipt of the trigger command. 

Thus, the brief summary of this aspect of the invention would nonetheless be understood 
to imply the use of a trigger request signal. In any event, claim 34 as filed refers 
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explicitly to the trigger request signal, and present claim 34 as amended is clearly based 
on that disclosure. 

Furthermore, the specification clearly teaches the synchronisation of a plurality of 
devices according to this aspect of the invention. As explained from page 24, linel8: 

"However owing to the USB connection topology, the arrival times of the SOf 
packet can differ between devices and, in addition, the USB specification allows 
significant temporal jitter in the SOF packet frequency with respect to the phase 
locked oscillator." 

From page 24 line 28 it is explained that: 

l To eliminate the problems of jitter the SOF signal is latched to the local oscillator." 

And from page 24 line 37 the application as filed states that: 

"Thus, figure 6 is a schematic diagram of a circuit 70 for monitoring the USB 72 
and locking the clock signal (phi) from a local clock 74 (with output frequency 
downshifted to 1kHz - if necessary - by clock frequency divider 76) to the 1kHz 
SOF packet of USB 72 in frequency and phase." 

The Examiner is also concerned that the specification does not support a trigger request 
signal being indicative of an initiating trigger request (but rather "transmitting a 
predetermined trigger request signal and a predetermined trigger command signal in the 
USB data traffic, indicative respectively a trigger request and said trigger command"). 
However, page 14 lines 2 to 4 of the original specification defines "configuring said USB 
devices to respond to said initiating trigger request signal by preparing themselves to 
perform said processes on receipt of said trigger signal". The "initiating trigger request 
signal" was intended to convey a trigger request signal configured to initiate a process, so 
the word "initiating" was merely intended to indicate thai what was referred to was a 
'"trigger request signal" that initiates the process. The actual signal was simply a "trigger 
request signal", so "initiating" was deleted in a previous submission. 

The Examiner is concerned that "transmitting said trigger request signal. . . to prepare said 
plurality of USB devices to each initiate said initiating trigger request" differs from the 
originally disclosed "sending and initiating trigger request signal. to prepare said USB 
devices to executive said trigger request", and that the original language appears to 
distinguish between "a trigger request signal" and an "initiating trigger request signal". 
As discussed above, these are the same feature: a trigger request signal is by implication 
"initiating". 

The Examiner objects to the order in which the "monitoring" step appears in claim 34. 
We monitor or watch for the arrival of the signal before we expect it to be there. 
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Examiner objects that claim 34 implies that the method involves monitoring the USB 
traffic for signals that have not yet been transmitted. However, this is indeed generally 
correct: the step of "monitoring traffic local to each of said plurality of USB devices for a 
trigger request signal and for a trigger command signal" is defined before "transmitting 
said trigger request signal. . . to each of said plurality of USB devices'', because 
monitoring or watching for the arrival of the signal may commence before it is expected 
to arrive. 

For this reason the claim refrains from specifying the relative order of these two steps. 
The Examiner has possibly read this step as "monitoring the signals so objected that one 
cannot monitor something that has not yet been generated. The claim actually recites 
"monitoring. ..for a trigger request signal and for a trigger command signal" (emphasis 
added), which has essentially the meaning of "watching out for" the signals. 

Thus, it is submitted thai the position of this step in claim 34 is suitable and indeed 
reflects the more common sequence in which the steps will be initiated. 

The Examiner again objects to claim 34 where it recites monitoring traffic local to each 
of the plurality of USB devices "for a trigger request signal and for a trigger command 
signal, indicative respectively of an initiating trigger request and of a trigger command". 
The Examiner asserts that.the quoted passage is unclear, and that there is insufficient 
information in the specification for it to be understood. 

As is well understood in this art, a trigger request signal prepares a device to receive a 
trigger command. It might be compared to "arming" an oscilloscope to receive a trigger 
signal. It is a preparatory command that sets the device into a specific state. The trigger 
command might be described as the "go" command. Claim 34 employs these two terms 
consistently in this well understood manner, and would be understood by those of 
ordinary skill in this art. 

The Examiner contends that claims 35 and 37 suggest that the trigger command signal 
comprises the same element as does the trigger request signal. As a result the Examiner 
is uncertain whether there is any difference between these signals, and how a trigger 
command signal or a request signal can include only USB packet signal structure or data 
sequences. 

The trigger request and trigger command signals can be defined to be any command or 
data sequence allowed within the USB specification. The present application does not 
teach that they should be identical. They are two distinct commands but each may 
comprise any such command or data sequence; nonetheless, they must both be adapted to 
perform their respective functions so if any particular combination prevents them from 
providing that functionality, that combination is excluded from the scope of claim 34 and 
hence claims 35 and 37 by the functions defined in claim 34 as performed by those 
signals. 

It is submitted, therefore, that these claims have clear bounds. 
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The Examiner rejects claims 32 and 33 as obvious in the light of US20Q2/0196884/US 
7,081,583/US 6,954,506/OS 6,678,760 in view of US 7,174,475 and further in view of 
US 6,654,897. 

The applicants respectfully disagree. 

Firstly, US 7,081 ,583 (Greco el al) is not prior art for this application, so it is submitted 
that the rejection based on that document be withdrawn. 

The Examiner contends that US2002/0 196884, US 7,081,583, US 6,954,506 and US 
6,678,760 teach locking the frequency of the clock of a USB device to a predetermined 
degree and, if applied to a USB tree, would allow all clocks to be synchronized. 

US 2002/0196884 teaches a method for ensuring that data in a USB packet is sampled at 
the centre of the "data valid*' window. This comprises a method for selecting a clock 
edge for starting the serial-to-paraliel transfer of the USB Serial Interface Engine. US 
200270196884 discloses on page 4: 

"[0042] The synchronisation pulse SPG_PULSE generated by synchronous pulse 
generator 14 is used to synchronise the logic in serial interface engine 16 for 
extraction of data from difference signal RXD and for the conversion of the serial 
difference signal RXD into a parallel format to generate parallel data PJDATA. 
"[0043] The maximum USB data jitter is 20ns from transition to transition. 
Therefore, the data must be captured near the centre of the bit period. This is 
accomplished by aligning synchronisation pulse SPG_PULSE a certain number of 
clock periods after a change in the difference signal RXD " 

However, this is not relevant to synchronizing a general clock in a USB device, but rather 
is merely concerned with data extraction from a received packet. 

US 6,954,506 discloses a method for data clock recovery from a USB data stream. This 
document is concerned with decoding the USB packet "sync" field for the purpose of 
decoding the pay load data of the packet. This is a fast locking circuit for capturing data 
and synchronisation is only transient. The process of clock data recovery synchronisation 
begins again only upon receipt of the next data packet. Column 1, line 67 states that: 
"USB 2.0 requires the USB receiver to recover a clock signal within a short preamble, 
that is, within a 4-clock period" and, from column 4, line 53, it is explained that: "The 
RXCX signal is a clock signal having the same frequency as thai of a clock signal used to 
transmit the R_DATA signal from a USB transmitter " From column 5, line 55 US 
6,954,506 further explains that: "Indeed, a clock signal recovery circuit according to the 
present invention can obtain a clock recovery signal synchronized with the received 
data..." 

Thus, the invention of US 6,954,506 merely relates to the field of data clock recovery, 
not to the synchronization. 
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US 6,678,760 discloses a method of delaying data packets sent and received through an 
Isochronous transfer, and teaches a double buffering method for synchronizing the 
delivery of dala packets across the USB. The suggested applications are in synchronizing 
telephony and video signals across USB, whereby data packets are received, buffered and 
delivered. US 6,678,760 also discloses a method for synchronising the clock rate of the 
USB host controller to a reference clock rate., which is merely a part of the USB 
specification and general Host Controller configuration documentation. 

None of these documents can be applied to a USB tree because, firstly, the clock data 
recovery techniques of US2002/0196884 and US 6,954,506 only synchronise the clocks 
for long enough to recover data from one packet. 

A High Speed USB 2.0 packet has a maximum data payioad size of 1 024 bytes, plus 
three bytes of handshaking. At a bus speed of 480Mb/s this means that the maximum 
packet duration is 17.2 microseconds. This is the maximum time uhat the clock data 
recovery inventions need to maintain clock lock. Synchronisation is lost within several 
packet times. The process of data synchronisation starts again from scratch with the 
receipt of the next packet. 

Also, these citations would in no way suggest a clock locking scheme to someone of 
ordinary skill in this art, whether as claimed in the present application or otherwise, 

US 6,678,760 relates to USB transmissions using the Isochronous transfer mode. 
Isochronous mode reserves a guaranteed bandwidth for each device but does not provide 
any protection for corrupt data. If a packet is coifupted, then data is lost, which is 
unacceptable for many applications. US 6,678,760 teaches a way of delaying a data 
packet within a USB device by double buffering, which is a clever way to achieve a 
modicum of synchronisation between delivery of packets in one USB transfer mode. 
However it does not work in other modes and combined with the two inventions 
discussed above does not lead to the claimed method of clock synchronisation across a 
USB tree. 

The second part of US 6 3 678,760 teaches a method of controlling the rate of a USB host 
clock by comparing it to a reference clock on one attached USB device. The present 
invention does not rely on controlling the rate of the USB host clock. 

The Examiner contends that it would have been obvious from US 7,174,475 to determine 
the relative propagation delay from a master USB device from a slave USB device. The 
applicants respectfully disagree. US 7,174,475 teaches a method of determining 
propagation delay by providing a "loop-back" path for a clock signal and measuring the 
round trip propagation time. This is a very simpl system where one wire carries the 
actual clock signal Out and another wire carries the signal back. 

However, USB is a serial communication bus. There are no "clock" signals that are 
transmitted by the master device, and definitely no means by which such a clock signal 
can be sent back for measurement of round trip time. Only dala packets are 
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communicated across the USB. It would therefore be far from obvious to someone of 
ordinary skill in the art to contemplate such a "round trip" time measurement, let alone 
determine how it might be implemented. 

In an illustrative embodiment of the present invention, a specific communication packet 
(essentially a message) is designated as the outgoing signal, and is used to start the timing 
process. The message is received by the USB device and processed internally. The USB 
processes the message and provides a response message which is used to stop the time 
measurement process back at the upstream point. This is a communication protocol and 
not a simple feedback of a clock signal on a wire; indeed, several months of research by 
the applicants were required simply to determine whether this approach would work. It is 
by no means obvious. 

It is also submitted that the person of ordinary skill would not combine the citations as 
suggested by the Examiner. They all teach distinct invention with diverse characteristics 
that are not readily combined, and which would not be considered by the person of 
ordinary skill as usefully supplementing each other. 

It is submitted, therefore, that claim 32 is inventive over the cited art. 

Concerning claim 33, US 6,654,897 discloses a method of delaying multiple data signals 
on a bus receiver and adjusting the bus clock such that the data is centered on the tL data 
valid" window. It does not relate to synchronizing clocks on multiple devices, so does 
not render claim 33 obvious. The Examiner appears to be suggesting that it is obvious to 
shift the phase of a series of clocks so that they are synchronised. Whether or not this is 
true, however, it is by no means obvious to do so in the manner defined in claim 35, 
resulting in an array o'f USB devices with local clocks of known relative phases. 

Again, it is submitted that claim 33 is inventive over the cited art. 



l35LT:6CW:69245:]:AUSXANDRfA 



PAGE 7/12 ' RCVD AT 8/2512008 1:16:41 PM [Eastern Daylight Time] ' SVR:USPTO-EFXRF-6/41 " DNIS:2738300 ■ CS!D:7 037399771 * DURATION (mm-ss):02-36 



